home *** CD-ROM | disk | FTP | other *** search
- Kim Peter Nyberg writes:
- > Marc Andreessen writes:
- > > The X Window System has this (to me, fatally flawed) design decision I
- > > hadn't suspected. X windows can only be so big. Up to the size of a
- > > 16-bit integer, in fact, in pixels. This is really really bad. This
- >
- > Well, unless we'll be seing >32k*32k displays in the near future, it's
- > not that bad.
-
- It is bad, because X's "virtual" window concept is a very convenient
- way of doing things, and because the decision to chop pixel
- coordinates to 16 bits is completely arbitrary -- Xlib in fact allows
- you to pass in 32 bits, but this gets truncated to 16 bits by the time
- the server gets it. It's just plain silly that it's not 32 bits all
- the way through.
-
- > > Mosaic does, which is lay out as much text as possible in the window
- > > and then give you convenient automatic inlined hyperlinks to the
- > > remainder of the text, partitioned into window-sized chunks. Then
- > > tell me who's making fatally flawed decisions.
- >
- > Hmmmh, no offence, but I think that's not not the correct way to
- > solve the problem.
-
- I agree that ideally we should be doing the scrolling ourselves, but
- like I said, that has a number of concomitant effects that we're not
- willing to accept right now.
-
- > Btw, have the current x-clients implemented non-blocking transfers?
- > It should be implemented in the common code, maybe it already is.
- > It's really too bad that we don't have the time to support erwise
- > (three of us are working almost full time at a software company, and
- > try to get on with our studies as well). Maybe in the summer ...
-
- I sure would like to have non-blocking I/O... I have looked at the
- Erwise code for this, and am thinking about stealing a lot of your
- changes, but haven't had time yet......
-
- Cheers,
- Marc
-
-
